Medical imaging systems generally are utilized for imaging parts of patient's bodies for physician review. Different imaging technologies, sometimes referred to in the art as modalities, may be used for imaging patient body parts. Examples of imaging modalities include computed tomography (CT), magnetic resonance (MR), ultrasound, positron emission tomography (PET), and nuclear imaging.
With respect to generating, processing, and displaying medical images, the development of medical imaging applications generally requires significant software development effort. The development is usually performed by highly skilled software practitioners since specialized software skills are needed to develop graphical user interface (GUI) based medical imaging applications. The software engineers, however, have limited domain knowledge. The clinicians who actually use the software applications typically lack the software engineering skills required for developing the applications. It would be desirable to provide an imaging system which is highly usable so that clinicians can develop imaging applications.
Known "programmable" systems enable clinicians to generate customized imaging applications. The most simple type of customization, for example, allows customization of display screens for a particular physician or other requirements. More complex customizations are required, for example, for research institutions.
The known programmable imaging systems, however, have a number of shortcomings. For example, one known programmable system does not provide the capability of creating/customizing new GUI elements. In addition, such system is not integrated into the base system, which results in visual, functional, and usability problems. Also, only an experienced programmer can add functionality to the system.
The following sets forth additional shortcomings in known programmable imaging systems. These shortcomings generally relate to script generation and execution, asynchronous execution, and review template editor functions.
1. Script Generation and Execution
Scripts typically are utilized for controlling the display and processing sequence of medical image so that a physician who reviews the image can view the image data in a desired format. For example, a particular physician may prefer a particular sequence of views be displayed when viewing a particular organ. A script can be generated to control the image display so that the desired sequence of views is generated and displayed.
Generating fully functional and usable scripts from graphical user interface (GUI) based software applications is difficult. Typically, scripts are generated by recording GUI events, such as button clicks, and replaying the events in the same application. In many situations, however, it is desirable to produce output scripts that can be used within the context of a different processing environment. In these situations, the semantics of the actions performed by the user must be captured rather than a mere sequence of GUI events.
There are many examples of applications that provide facilities for recording and playing back GUI events at various levels. One such known program records the mouse movements, button presses and keyboard clicks, and replays these events. Even small changes to the GUI, however, requires that the events be re-recorded to capture the changes.
Another known application records the GUI widget (buttons, sliders, etc.) that was activated (pressed) rather than simple mouse and keyboard actions. This program alleviates the problem with minor GUI changes, but still requires playback of the created script on the original application. That is, this program only enables recording an application and playing it back using the same application. The scripts produced are not designed for use outside of the instrumented application. Additionally, the syntax of the output scripts produced are completely predetermined and are not user configurable.
2. Asynchronous Execution
Known medical imaging systems have a client server architecture. A major advantage of this architecture is that the application process can remain attentive to the user because the application does very little processing. Most processing is handled by servers. The servers, in turn, are "specialists" at providing a particular service and may in fact be running on specialized hardware, optimized for particular tasks. A good example of this specialization is a processing server having hardware acceleration of common image processing operations. The ability to access network distributed resources is a major advantage of the client-server architecture.
With respect to task execution in a client-server architecture, the application makes a request for some service. Because the servers(s) which process the requests can reside anywhere on the local area network, the application must wait for the operation to complete before reporting the results back to the user. The amount of time the application must wait depends on many factors, including the speed of the server. To remain interactive, the application must yield, which typically is performed by returning the execution thread to the idle state so that the application can respond to other user requests. This yielding function is fundamental to a highly interactive application. When the reply from the previously queued request arrives, the application must then restore the processing context of the application to its prerequest state and present the results of the operation. This process is commonly referred to as asynchronous behavior.
Experience has shown that implementation of the request-yield-reply paradigm introduces significant programming obfuscation because single operations must be broken up into multiple execution threads, state or context information must be managed to bind the request side to the reply side, and subtle, difficult to diagnose timing related errors can creep into the code due to multiple interactive asynchronous execution threads. The resulting code also is difficult to maintain. These factors have significantly reduced the productivity of programmers in this environment.
Moreover, the asynchronous execution application code is complex and advanced computer programming skills are required to develop code in this environment. For example, a six to eight week training period is typical for an experienced software engineer in the request-yield-reply development paradigm described above. Much of this training period is spent appreciating the finer points of asynchronous software programming. Further, the complexity of asynchronous programming makes it an unsuitable approach for most end users who are not usually software engineers. For the most part, developers of client-server applications have accepted the development inefficiencies of the request-yield-reply program paradigm as a penalty for the additional flexibility and high interactivity of client-server applications.
In addition, and in an attempt to avoid some shortcomings of asynchronous operation, some approaches exist in which database functions behave synchronously. For example, in one known approach, a programmer detects abnormally long operations and takes corrective actions. The mechanism used to implement this behavior is a polling mechanism where the GUI is frozen during the wait phase, i.e., it does not implement a true yield. In medical imaging and real time control applications where response latency must be very low, this type of mechanism may not be acceptable since an operator may have to respond to an emergency situation during long transactions. A further disadvantage of this approach is that long operations cannot be cancelled during the wait period. It would be desirable to provide a system in which application interactivity is preserved even during long transactions while eliminating the chores of coding in a request-yield-reply paradigm and maintaining its benefits.
3. Overlap Detection and Correction
In developing medical imaging applications, a frequent activity is to construct a review template. A review template is a graphical presentation of images, curves, text and other patient information relevant to the review of medical diagnostic information. In constructing a review template, rectangular cells typically are constructed, the arrangement of the cells on the screen is selected, and the specification of attributes for those cells is generated. Cells can contain images, curves, text, and other information relevant to the diagnostic process.
For many physicians who review patient information, the presentation and format of the information is very important. Therefore, many physicians demand personalized review templates to suit their personalized diagnostic needs. To enable end user customization of review templates, an imaging system must provide an easy method for constructing or modifying review templates. In addition, the review template editors preferably are optimized for particular tasks.
One known system for constructing a review template includes the use of graphical review template editors which provide a point and click interface for creating the templates. The graphical editor has been found to be an easy way for the end user to construct review templates.
One shortcoming of known review template editors, however, is that such systems require the user to correct for cell overlap. Specifically, the cells are tiled and never overlap because overlap would occlude important diagnostic information. The user therefore must painstakingly and meticulously position cells using the mouse or a property editor. To aid in this task, some review template editors include tools such as a zoom mode to enable more accurate alignment. Other known systems provide tiling post-processors which pack the cells in a minimal geometric configuration. For medical imaging review template construction, these tools are either too time consuming in execution or lack flexibility because they do too much for the user, as in the case of the tiling post-processors. It would be desirable to provide an automatic overlap detection and correction algorithm which enables increased ease of use by accelerating manual cell alignment tasks.
The above described shortcomings associated with known programmable systems preferably would be overcome in a programmable system which is extremely user friendly so that clinicians can relatively easily and quickly develop imaging applications. In addition, and with respect to scripts, such scripts preferably could be used in many different environments so that regardless of the environment, images and data can be displayed for physician review in accordance with that physician's desires without significant additional effort and expense. Generation of such scripts also preferably would be simplified and interactive. Further, and as described above, it would be desirable to provide a system in which application interactivity is preserved even during long transactions while eliminating the chores of coding in a request-yield-reply paradigm and maintaining its benefits. Also, and for review template generation, it would be desirable to provide an automatic overlap detection and correction algorithm which enables increased ease of use by accelerating manual cell alignment tasks.